I think this is pretty dangerous since it silently throws away assignments of readonly attributes without the developer knowing about it. This is the exact problem that config.active_record.raise_on_assign_to_attr_readonly was looking to address.

I see some viable options:

1. We consider paper_trail's reify operation as a "dangerous" operation that automatically disable attr_readonly declarations (somehow) and forces the attributes to be rewritten.
2. We take the stance you can't have both worlds. As in, you can't reify a record if it's going to set a readonly attribute. This is basically not changing anything.
3. We only set the value iff it's a different value. This allows the reify to work in some cases and fail (loudly) in others. This seems a little odd to me, but still, it's an option.

We only set the value iff it's a different value. This allows the reify to work in some cases and fail (loudly) in others. This seems a little odd to me, but still, it's an option.

This is the approach in #1473. Any concerns?

I talked about this with someone today and came to the conclusion that option 1 is actually the best. Option 3 happens to work sometimes for folks. However, if you consider the business logic decision to add attr_readonly to an attribute at a certain/later point in time now affects your ability to reify a record.

In my opinion, reifying a record is a break-the-glass operation that should just always work (similar to update_column). At the very least, the assignment should just always work. Devs can then call save(validate: false) if they want to persist the an invalid record.

As for the implementation of option 1, I think papertrail will have to do some tricks to temporarily empty out ([]) the readonly array for a model while it's doing it assignment for the reify. Or, it can use private apis to set the attributes directly, bypassing the raise. Or, maybe Rails will take a patch to allow a bypass block similar to no_touching.